Computerized devices control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized device. The cost of not discovering a bug may be enormous, as the consequences of the bug may be disastrous. For example, a bug may cause the injury of a person relying on the designated behavior of the computerized device. Additionally, a bug in hardware or firmware may be expensive to fix, as patching it requires call-back of the computerized device. Hence, many developers of computerized devices invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized device.
During the testing phase, a sample of all possible behaviors of the computerized device, also referred to as a System Under Test (SUT) or target system, is inspected.
The testing phase may be planned, such as by determining which test cases be executed. Additionally or alternatively, given a test suite, a reduction of the size of the test suite may be desired without reducing the coverage of the selected subset. It is known that a functional coverage model, also referred to as a “functional model”, may be useful for such tasks. The functional coverage model defines a triplet: functional attributes, a domain for each functional attribute, and a set of restrictions. The functional attributes may be any attribute of the SUT, such as for example a type of web browser being used, an underlying Operating System, a number of threads operating, whether the output was printed. The domains may define for each attribute a set of possible values. For example, the web browser may be Microsoft® Internet Explorer®, Google® Chrome®, or Mozilla Firefox™. Similarly, the operating system may be Microsoft® Windows®, or Linux™. The cross-product of the different combinations of the attributes defines a functional coverage test-space. The test-space comprises a set of coverage tasks, each representing functional requirements to be tested: one requirement per functional attribute, and the requirement is that the functional attribute will exhibit the behavior of the value of the coverage task. The coverage task may be seen as a tuple of one value per attribute. In a functional coverage model in which there are three functional attributes, one having three possible values, the second having two possible values, and the third having ten possible values, the cross-product test-space comprises sixty (60) coverage tasks. In some exemplary embodiments, a set of test cases are represented by a set of coverage tasks, each corresponding to a different test case.
The functional coverage model may further comprise a set of restrictions defining a series of values of different attributes that may not appear together. For example, consider a functional coverage defining two attributes: ACTION and USER. The ACTION attribute may be each of the following values: RETRIEVE, STORE, and MODIFY PERMISSION. The USER attribute may be each of the following values: ADMIN, USER, GUEST. In some cases, a guest user cannot modify permission. A restriction may be defined to indicate that the couple (GUEST, MODIFY PERMISSION) is not a valid couple. The fact that a trace does not comprise an entry covering a coverage task that includes the couple does not affect the functional coverage. In other words, all possible coverage tasks—which together form the maximal possible coverage with respect to a functional coverage—do not include any coverage task that comprises the restricted couple. It will be understood that restrictions may be defined with respect to a combination of values of different attributes, and not necessarily with respect to a complete tuple of values. Furthermore, the restriction may be any constraint on combination of values, which may be represented using a Boolean formula over the functional attributes and associated values.